feat: OneDrive and Local Folder sync providers + Google Drive re-auth overhaul - #250

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…re test

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

- Add filesystemCore stub to cloud-provider-core-registry (never called
  at runtime since FilesystemProvider.supportsWorkerDownload = false)
- Widen VolumeMetadata.cloudProvider from narrow literal union to
  ProviderType, fixing cascading errors in cloud-fields.ts,
  library-placeholders.ts, and download-queue.ts

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

processDownload previously only handled supportsWorkerDownload=true. For the
filesystem provider (which sets that to false), downloads were silently
skipped — the queue item stayed in 'downloading' state forever and blocked
all subsequent items. Add a main-thread branch that downloads via the
provider's downloadFile method, extracts the CBZ with @zip.js/zip.js, and
reuses the existing downloadSidecarEntries + processVolumeData pipeline.

The regex on error.message did not match Chrome's DOMException.message
(which does not contain the string 'NotFoundError'), causing spurious
DELETE_FAILED errors when a series folder was already gone during sync.

…ders

The filesystem provider cannot upload from a worker because a
FileSystemDirectoryHandle is bound to the window that received it via
showDirectoryPicker — structured-cloning it to a worker does not carry the
user-granted permission. Introduce a supportsWorkerUpload flag on SyncProvider
(parallel to the existing supportsWorkerDownload) and, when a provider opts
out, compress + upload the archive and any sidecars on the main thread via
provider.uploadFile. Worker-capable providers (Google Drive, MEGA, WebDAV)
are unaffected.

Previous fix bypassed the pool entirely and ran compression + upload on the
main thread for filesystem. With a parallel queue that meant N volumes could
load, compress, and buffer simultaneously with no shared-memory accounting
and no provider concurrency cap.

Instead, submit the same pool task used for real providers but in the worker's
'null provider' compress-only mode. The worker still does the CPU-heavy
compression (throttled by WorkerPool + sharedMemoryManager); the main-thread
onComplete then performs the single filesystem write via provider.uploadFile
while the task's memory reservation is still held. Sidecars follow the same
path. Worker-upload providers (Drive, MEGA, WebDAV) are unchanged.

Previous fix bypassed the pool and did blob read + decompression + processing
on the main thread for filesystem. Even with the queue being serial that
blocks the UI during decompression and leaves memory untracked by the shared
memory manager.

Instead, use the worker's existing decompress-only mode: prepareData reads
the blob on the main thread (required — FileSystemDirectoryHandle is bound to
the window) and passes it to the worker, which decompresses and returns
entries. Memory reservation, provider concurrency gating, and shared memory
tracking all apply uniformly with the existing worker-download path.

Adds design for a fourth real sync provider using Microsoft Graph API via
MSAL.js. Multi-tenant (common) auth covers personal + work/school accounts.
Worker-capable core follows the Drive/WebDAV pattern so WorkerPool throttling
applies uniformly.

The catalog's providerNames map was missing the two new providers, so their
placeholder breakdowns rendered the raw keys ("2 filesystem") instead of
friendly labels. Add Local Folder / OneDrive entries.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

# Conflicts:
#	package-lock.json

…ovider

# Conflicts:
#	src/lib/views/CloudView.svelte

…ovider

# Conflicts:
#	src/lib/util/sync/providers/mega/mega-provider.ts

… on all providers

…n_in_progress

…redirect

… clients

…eouts, 202 drain

…n matches)

…onfig-gate OneDrive

…ds progress